Примеры технологических карт.
§ 5. Технологическая карта — основной документ для изготовления деталей
По факту видим, что это операционные технологические карты, бывают и другие.
1) Сверху представлен результат.
2) Снизу операции содержащие: а) номер, б) словесное описание, в) чертёж, г) объекты, такие как инструменты или даже то, над чем проводится работа.
Объекты больше ссылаются на инструменты нежели материалы. В том же примере по ссылке, рубанок должен строгать, а не рубить. И в словесном описании пишут "Строгать А", а не "Строгать рубанком А". При том, что в инструментах верстак, рубанок, линейка. Кто знает, может быть строгать нужно линейкой или даже верстаком. На том же чертеже операций можно было бы явно начертить рубанок, где показана траектория движения объектов.
Я к тому, что убирать объекты относящиеся к инструментам из словесного описания или чертежа на том основании, что они описаны в инструментах неправильно. Как бы догадайся теперь как их использовать. А если прописать всё до конца, то колонка объектов, хотя в изначальных операционных технологических картах это оборудование, инструменты и приспособления, не особо и нужна.
Теперь вспомним про источники информации в иных форматах. Прежде всего хотелось бы дать им оценку с точки зрения технологичности, то есть получения результата без дополнительных мозговых затрат.
Самые понятные обычно уроки в формате последовательно перечисленных операций.
1) ...
2) ...
3) ...
По факту это и есть операционные технологические карты, но без колонки чертежа, которую иногда заменяют рисунками и дополнительного описания объектов. Этот формат хорош прежде всего тем, что пользователь может пройтись по пунктам и выполнить их без сложного домысливания, как это было бы с полотном текста используемых в неструктурированных уроках или книгах.
Другой пример книги. К ним можно отнести всевозможные полотна текста в виде статей и прочего. Ведь что такое книга, обычно это как раз и есть набор статей на определённую тематику сшитых вместе. Разница лишь в том, что эти статьи пытаются покрыть какую-то тему, именно пытаются, не всегда это удаётся. В конце концов объём книг хоть и велик, но ограничен, как и сознание автора.
А теперь вопрос, чем один человек отличается от другого с точки зрения труда? Ответ получен в книге "Капитал" Карла Маркса. Эта книга описывает возможности человека с точки зрения физиологии. Трудящийся подключает к своим органам орудия труда благодаря чему возможности того, что он может сделать расширяются. Но в тоже время человек остаётся человеком.
Грубо говоря можно копать голыми руками, можно управлять экскаватором посредством его органов управления, а можно запрограммировать на копание машину с помощью компьютера. Это абсолютно разные инструменты и они требуют разных навыков от человека, но сам человек при этом физиологически тот же самый, никаких дополнительных органов у него не появится, а сам он способен меняться лишь в определённых природой пределах.
Технологические карты, в частности операционные, для человека это тоже самое, что программы для компьютера. В той же школе пытаются научить решать задачи выдавая по сути одни и те же примеры не меняя сами операции, но меняя объекты в условиях задачи. Но рано или поздно школьник, а то уже и взрослый человек забудет способ решения. А ведь именно набор знаний определяет специализацию.
Я клоню к тому, что людям не нужно переизобретать что-то заново им нужен набор готовых решений для того, чтобы они могли менять свои специализации. Если постоянно что-то переизобретать или пытаться вычленить из полотен текста, то количество операций будет уменьшено за счёт того, что решения придётся хранить в голове.
Разница между продавцом, программистом или ещё кем-то не просто в качественной сложности, в огромной степени ещё и количественной. Причём программирование это не только кодирование. Если программист не знает предметную область продавца, то ему сначала придётся её понять и только потом закодировать. Продавец получивший навыки кодирования в принципе мог бы что-то закодировать по своей предметной области, но не по другой.
Основной минус наборов решений в том, что их нужно создать. При этом они могут очень сильно отличаться по качеству как описания, так и чертежа. Успехом можно было бы считать, если бы некая фокус группа новичков в некой предметной области могла с ходу выполнять операции по технологическим картам. Конечно, это не делает такие карты идеальными, возможно путаница в названиях операций и объектов, а так же ошибки в чертежах.
Описание с помощью текста и описание с помощью чертежа в какой-то мере является попыткой выразить одно и тоже. Я уже не раз об этом писал в своих предыдущих статьях. Ключевая же разница, что чертёж использующий только линии можно понять вне зависимости от словесного языка.
В компьютерных системах везде используется текст, даже просто в каком-нибудь меню. Текстовое описание представленное на языке пользователя помогает проще находить "рычаги" управления, нежели только значки. Однако тоже самое описание представленное на неизвестном языке заставляет тыкать всё подряд и ориентироваться на геометрию расположения элементов, а не на надписи.
Таким образом значки на которых содержатся не абстрактные символы, а реальные геометрические объекты выигрывают в универсальности, но проигрывают в качестве и скорости активации ассоциативных связей. Потому у меня есть предположение, что если описать сначала действие в виде чертежа без текста, а потом уже добавить описание в виде текста, то сам чертёж получится более наглядным, чем если сначала описать операцию текстом, а потом попытаться начертить по нему чертёж.
Колонка объектов включает оборудование, инструменты, приспособления, а так же возможно и материалы над которыми производятся операции. Может быть и не нужна, ведь можно усилить словесное описание, а сами объекты вынести отдельно. С другой стороны тщательное прописывание таких данных в каждой операции может пригодиться для улучшенного анализа как со стороны изготовителя операционных технологических карт, так и со стороны исполнителя, которые эти карты использует.
Фактически это колонка позволяет провести предварительную подготовку. Другое дело, что здесь мы встречаемся с той же проблемой, описывать ли объекты в виде только текста, только чертежа или и то и другое вместе. Понятно, что комбинированный вариант лучше хотя бы потому, что вне зависимости от привычек конкретного человека позволяет ему ориентироваться в инструкции двояким образом. А если он ещё и не знает разговорный язык на котором написана технологическая карта, но может её использовать при этом являясь новичком, то есть вероятность, что она сделана качественно по части чертежей.
Карты интервальных повторений рассчитаны на многократное повторение в следствии чего человек запоминает заложенную в них информацию. Частный случай таких карт позволяет проверять знания в сложных случаях набирая текст, в простых выбирая области на изображении или текстовые варианты ответов.
Операционные технологические карты создаются с другой целью, хотя ничто не мешает оформлять их в виде карт интервальных повторений. Ведь самый примитивный вид последних и вовсе не проводит никаких проверок. Но если смотреть с такой точки зрения, то операционные технологические карты можно было бы оформлять не только в формате карт интервальных повторений (apkg, mtx), но и с помощью текстовых документов (doc, odt), табличных документов (xls, ods), презентаций (ppt, odp), чертежей (dxf, fcstd), веб-страничек (html) и так далее.
Потому вопрос здесь не в формате операционных технологических карт, а скорее в их назначении и качестве. Поскольку исполнителем является сам человек, то какой-то особой автоматизации не предполагается. Если есть способ обойтись без лишних операций, то очевидно он будет указан в операционной технологической карте с меньшим количеством телодвижений.
До сих пор речь шла обо всём. В конце концов подобным образом можно описать всё что угодно, как строить дом, как делать ремонт, как готовить блюдо. С другой стороны в программировании можно было бы сосредоточиться на кодировании, проектировании, тестировании и прочих операциях присущим программистам.
Например:
1) создать недетерминированную машину состояний на языке structured text.
2) вывести упрощённый список всех коммитов в репозитории git.
3) переместить файл в gnu/linux используя консольную команду mv.
И всё в таком роде.
То как это всё будет выглядеть можно узнать лишь начав создавать операционные технологические карты. Дело в том, что в программировании очень много завязано на словесные описания, причём ещё и на английском языке, что затрудняет понимание тем для кого этот язык не родной, и очень мало на чертежи.
Про неродной язык ещё стоит отметить, что программы можно было бы писать и на родном языке, как минимум с транслитерацией. Конечно, здесь мы столкнёмся и с определёнными недостатками такой практики. Думаю пока не стоит развивать эту тему, тем более речь о другом.
Однако стоит отметить, что какие бы слова не применялись в операционной технологической карте в качестве технических терминов, сама карта должна быть написана на разговорном языке того, для кого она предназначена.
Продуктом кодирования безусловно будет код и программа это код. Если хочешь научить человека кодированию, то сколько не пытайся как-то изобразить код иначе, всё равно получится код. Программист должен набрать код в виде текста, именно этому должна учить операционная технологическая карта. Но код не объясняет предметную область.
Операционная технологическая карта это программа по которой работает человек как её исполнитель. А код над которым он работает это программа для компьютера. По идее сам код можно засунуть как в описание, так и в чертёж. Но ни то, ни другое не объясняет для чего нужен этот код.
Естественно операционная технологическая карта этого тоже не объясняет. Тем более на ней явно указано, что она именно операционная. Как говорится нажми на кнопку, получишь результат, вот основной посыл. Для иного нужны или другие виды технологических карт или что-то ещё.
С текстом всё более ли менее понятно, лучше всего использовать текст в формате utf-8. А там уже оформлять как угодно согласно формату хранения, если кто-то хочет усложнить этот процесс. Другое дело чертёж.
Лично я думаю, что хотя начальным форматом в котором редактируются данные может быть что угодно, растровое или векторное изображение, чертёж CAD и многое другое, то конечным должен быть рисунок в формате svg. Для этого нужно провести векторизацию растрового изображения или проецирование и сохранения изображения CAD в виде svg.
Но это всё если говорить о чистовой законченной работе по созданию операционной технологической карты. В программировании это называют релизом или по русски выпуском. А на черновике можно творить что угодно, вплоть до ручных набросков.
Здравствуйте, Salih, Вы писали:
S>если вы босс, то характер производства технологических карт один, если вы тимлидер, то другой, если программист-одиночка, то технологические карты для себя это вообще отдельная песня. но помимо самих карт, не менее важен карательный механизм за отступы от карты, приёмка и контроль.
Я предполагаю, что формат операционных технологических карт должен быть привычен, а значит единообразен. Это не значит, что он будет единообразен для всех. Но для примера те же графические приложения для десктопа как правило содержат заголовок окна, уже в окне сверху расположено главное меню, снизу строка состояния, а панели инструментов люди ожидают увидеть или под главным меню или вокруг контекстной области.
Таким образом босс, тимлидер и программист-одиночка это наборы операционных технологических карт, где важнее то, что там написано внутри, нежели как это оформлено. По поводу оформления, сколько смотрел, всё в итоге сводится к примеру приведённому мною выше. Эту таблицу можно исказить в угоду чертежей размер которых ограничен форматами A0..An и другими, что может снизить ожидания от расположения элементов. Тем не менее содержимое окажется тем же самым.
Для составителя операционных технологических карт можно составить операционные технологические карты, где будет указано как их создавать и проверять по некоему соглашению, которое так же может перерасти в стандарт некой организации и даже выйти за её пределы. Основная мысль у меня о том, что без технологических карт сотрудники должны слишком много домысливать. А сложность операционных технологических карт именно в программировании в том, что их будет очень много. Одно дело оперировать десятком операционных технологических карт, другое десятком тысяч.
Я не стал расписывать предпосылки этой статьи, а они были. Взять те же прайс-листы, по русски списки-цен. Читая "Капитал" Карла Маркса я задумался, почему один труд оценивается так, а другой иначе. Он так же поднял тему, что труд может быть не востребован. А если труд не востребован, то отношения между людьми в капиталистическом обществе полностью прекращаются. И напротив, труд может быть востребован, но исполнителя не будет.
Есть такие понятия как ЕНВИР — Единые нормы времени и расценки. Всё же люди пытались свести труд к некому единообразию. Ведь по сути, если завтра все текущие исполнители дружно поднимут цену, то не останется ничего другого как платить, отказаться от услуг или попытаться кого-то обучить, себя или других людей.
Опять же с точки зрения операционных технологических карт более важна точность исполнения, нежели придумывания чего-то на ходу. И если работа выполняется не удовлетворительно, причём когда всё исполнено точь в точь по операционной технологической карте, то значит пора менять технологию на улучшенную. Некоторые люди считают, что занимаются "творческим" трудом, но действительно ли это так.
Для примера возьмём расценки:
создание точки входа в приложение 1шт. (50 рублей, 2 минуты)
создание заготовки файла перевода 1шт. (150 рублей, 5 минут)
добавление виртуального сервера 1шт. (200 рублей, 5 минут)
отварить картофель 1кг (50 рублей, 60 минут)
отварить морковь 1кг (60 рублей, 60 минут)
Почему это стоит столько сколько стоит? Откуда взялись эти цифры? Может быть от времени исполнения, которое можно изменить сменив технологию и инструменты или нет.
К тому же использование одной технологической карты, которую потихоньку досконально запоминаешь всяко эффективнее, чем тысячи, которые не помнишь и которые можно исполнить только по "бумажке".
Тоже самое касается массовости, одно дело варить 1кг картофеля в кастрюле, другое дело 10 тонн (10'000кг) в цистерне. Провести десять тысяч варок чтобы достичь того же результата, а человек при этом нисколько в физиологическом плане не меняется.
Потому тема это более глобальная, чем может показаться на первый взгляд. Она касается не только технологий, но и оценку с точки зрения труда людей, распределение обязанностей по ролям.
Причём, когда мы говорим о ролях, речь не только в умениях использовать определённые технологии. Это ещё и общественные отношения. Если босс не обязан ничего уметь, а только пользоваться результатами чужого труда и система не разваливается, то такое тоже может существовать.
